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Recommendations of Policy Panel 


Should there be an SPDS? 

Making space physics data broadly and readily accessible for scientific inquiry is an activity in which the 
space physics community is currently engaged and which is a necessary component of a viable, modem 
research activity. Recognizing these activities collectively as the “Space Physics Data System” (SPDS) is 
most appropriate. 

What should the Philosophy of the SPDS be? 

The SPDS should be a distributed data system designed, developed and operated by scientific users of 
space physics data. SPDS should make maximum use of existing facilities including data centers, project 
data management units, and principal investigators. SPDS should be implemented through existing comput- 
er networks using appropriate standards and software. 

What is the appropriate funding level and how should SPDS 
funding be related to funding levels of other SPD activities? 

The workshop feels strongly that the entire data analysis effort within the Space Physics Division (SPD) 
is seriously underfunded, and total resources within this area should be significantly increased. We believe 
that the SPDS should serve to enhance the data analysis environment for researchers in the field, and that 
therefore, significant future funding for SPDS should represent new resources, made available to the Divi- 
sion to support the Division Data System in a move toward achieving parity with other Divisions, which 
already have been given large Data System resources. The need for an SPDS is real and urgent. Therefore, 
we urge the Division to initiate the SPDS now, with existing (albeit limited) funding. As the utility of the 
SPDS grows and is recognized, funding should grow appropriately. The ultimate funding level should be 
determined by the value of the user-evolved SPDS to the community, and may well turn out to be of the 
same level as now exists in the Solar System Exploration and Astrophysics Divisions. 

If there is funding, how should it be distributed to the community? 

Funding should be awarded competitively through peer review. In the initial stage, this could be through 
an augmentation or supplement to scientific investigations selected under existing peer review programs. In 
anticipation of future increases in funding, support could then be distributed through a separate Announce- 
ment of Opportunity. 
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In the current austere funding environment , what should the SPDS look like? 

The paucity of funds make it impossible to incorporate the diverse data sets into a comprehensive system. 
The current paradigm must therefore be reliant on the Master Directory to indicate what data are available 
and where they are located, the use of existing software and human systems to retrieve data, and die use of 
data format translators to import data into an investigator’s own analysis system. 

What are the important objectives of an SPDS, and in what priority? 

Access to quality data is the most important objective, with curation and information about the data being 
integral parts of any accessible data set. As pointed out in the Concept Document on NASA's SPDS, support 
for dissemination of data analysis tools is important but of secondary priority to the above three objectives. 
Awareness of recent developments in data management technologies is important but ot lowest priority of 
the five objectives. 

What next? How should an embryonic SPDS be structured to continue the activity, in the current climate? 

We expect the management structure to evolve as the SPDS becomes better defined. Initially there should 
be a volunteer Discipline Coordinator from the user community for each of the four SPD branches and a 
Project Coordinator. The coordinators will survey and inform their communities and begin SPDS activities. 
A follow-on users community workshop should be planned for about one year from now. 

What should be the relationship between SPDS and Network services? 

The success of SPDS depends upon the existence of a reliable, highspeed, worldwide, multi-protocol 
communications network. 

What should be the relationship of SPDS to new projects and proprietary data ? 

Participation in SPDS by all current and future division-related investigations, and their Principal Investi- 
gators during the active phase of missions should be facilitated. This requires recognition of and adequate 
safeguards for the protection of data as long as they remain proprietary. The SPDS should be structured so 
as to permit the dissemination of proprietary data to team members and guest investigators, and to allow for 
easy migration of data into the public domain. 
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Should SPDS support the software library ? 

A software library catalog that indexes into software distributed across the network should be an integral 
part of SPDS. Software should include data processing, translation, analysis, and visualization routines, and 
could include ancillary software such as models, simulation results, etc. 

What should be the relationship between the SPDS and existing information services activities (e.g. 
NSSDC cfc SPDF) within Space Physics? 

Existing NASA data services provide for deep archiving (a permanent repository), access for internation- 
al collaborators, broad cataloging and directory services, and Division-wide coordination (e.g. Satellite Sit- 
uation Center) through the NSSDC. We see these activities as an important part of SPDS and recommend 
the continuation of these activities by inclusion of NSSDC as one of the SPDS nodes. 
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Recommendations of Data Issues Panel 

The Data Issues Panel started with a set of assumptions that were generally held by the members but not 
specifically debated. These general assumptions formed a framework upon which the discussions of specif- 
ic issues were based. 

1 . SPDS is a good idea and should exist. 

2. 11 should not be ambitious but rather should start by formalizing the informal system that already ex- 
ists. 

3. The first goal of SPDS should be to facilitate the exchange of useful data between scientists with 
greater ease. 

(a) This will maximize scientific output 

(b) The effort would be voluntary 

4. The SPDS should be accessible and usable by as many people as possible. 

(a) SPDS should include non-NASA data sets such as those funded by NSF. DoE, other federal 
institutions, and universities. Both US and non-US data suppliers and users should be in- 
cluded. The needs of developing nations should be considered. 

(b) To include a maximum number of participants, the use of the SPDS should require only 
widely available technology and hardware and should need minimal technical knowledge 
of computer systems. 

(c) To encourage wide participation, there should be no undue burdens on data suppliers or 
system users. There should be few “requirements" to which data suppliers or users would 
need to conform. However, there should be many “suggestions” which can be used to guide 
those who wish to participate. 

5. There should be “rules of the road" that allow Pi’s or curators to both control and facilitate access 
to and use of the data. These rules may vary for different data sets. 

6. Documentation should be available for all data and should be as thorough as possible. The level and 
completeness of documentation will also vary among data sets. 

The Panel considered the first steps toward a Space Physics Data System. The Panel envision that an early 
incarnation could begin to develop even in the absence of any funds through voluntary effort. Tlius, one 
guiding principle for including data sets was that beggars can be choosers. 
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Minimum Requirements for a Space Physics Data System (SPDS) 

1. There must be a centralized listing of all data sets that are a part of the SPDS. This listing should in- 
clude data sets that exist at host 

institutions but arc off-line. The listing should be kept current. It should include the following items, at a 
minimum: 

(a) Source of data (e.g. S/C, ground station, etc.) 

(b) Type(s) of measurement (e.g. magnetometer, particle telescope, etc.) and parameters avail- 
able (e.g. flux, moments, etc.) and their units. 

(c) Time span of data, plus information on nature of data coverage (e.g. complete polar passes 
only, etc.) 

(d) Volume of data set 

(c) Ephemeris data location (if not contained in data set) 

(0 Cognizant Personnel (PI., curator) 

(g) Means of access/delivery (e.g. on-line, CD-ROM near-line, magnetic tape, | punched 
cards?], etc.) 

(h) Restrictions 

(i) Format 

• Abstract of data description 

• Available software to read and/or display data set 

• Software to translate the data set into a “standard” format, if necessary 

• Detailed format description. 

2. It will be the curator's responsibility to maintain and extend the data set, notifying the SPDS Project 
Coordinator of any and all changes to the data set, including new data, re-calibrated data, etc. These 
changes will be passed on to the user community. 

3. In the event that a data set is “endangered”, either through loss of funding, lack of cognizant person- 
nel, deterioration of media, etc., the SPDS Project Coordinator shall communicate this to the entire 
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SPDS community, and identify means of “saving” it, if possible and determining whether the data 
set is considered “important.” 

4. A means of controlled access must be established so that a Pi’s proprietary rights to a data set are 
respected. 

The Structure and Layers of SPDS 

The SPDS is a grass-roots effort defined by the following structure. Each layer of the SPDS is described 
by that element's functions, responsibilities, and requirements: 


Figure TBD 


1. Project Coordinator(s) (PCs) and staff: 

• The Project Coordinators charges arc: 

• To advertise to the appropriate community the existence, mission, and operation of the 
SPDS 

• To compile information provided by SPDS data nodes regarding data and generic soft- 
ware, availability, points of contact, access, etc., at their institutions, and to dissemi- 
nate these inventories to the community 

• To establish rules of the road for data exchange and SPDS participation 

• Ideally, Project Coordinators are scientists within the community who arc presently en- 
gaged in proto-SPDS activities. 

• A possible structure would be one overall Project Coordinator, assisted by four “Branch" 
Coordinators. Initially, these might be voluntary, rotating positions. 

• Project Coordinators should encourage similar SPDS-likc activities within non-NASA 
agencies and the international community. 

• Coordinators should be the sounding board of the community and should play an active 
advisory role in data systems requirements for future missions. 

• Coordinator should monitor system use and track data distribution (retain log of “users" 
as well as nodes) 

• Coordinators should identify possible duplication of effort (provide information on the 
“official” approved repository in the event of discrepancy) 
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• Coordinators should notify users about data set additions (subtractions), system changes, 
etc. as needed 

• Coordinators should encourage, but not require, community involvement toward devel- 
oping “standards” and community-shared efforts 

• Coordinators should identify and support “endangered” data sets 

• Coordinators should promote communication with other noil-traditional agents for data 
archival/curat ion (e.g., university libraries). 

2. SPDS Data Suppliers (Nodes): 

• Nodes shall: 

• Provide to the PC’s a list of data sets available at the Nodes institution 

• Provide description of how to access available data 

• Provide data descriptions Provide Pi/curator supervision and assistance to users if pos- 
sible, and if desired 

• Provide translation code to access data A Node must be connected to Internet. 

3. SPDS Data Users: 

(a) Should have an Internet connection Must abide by the “rules of the road” Must notify the 
Pi/curator about intentions for data and provide preprints of publications. 

(b) The curatorial role of the original institution where the PI is (was) affiliated should be rec- 
ognized and developed. Since one of the obligations of an archiving system must be to 
make data available to future generations of researchers, the SPDS should investigate the 
use of universities and institutions which have mechanisms that are designed to provide 
long-term curation of scholarly data bases and raw research materials in other disciplines: 
to wit, libraries, and museums. A low-cost program that the SPDS olficc might undertake 
would entail: 

1) Selling the concept of scientific data curation responsibility to the libraries and mu- 
seums at institutions. 

2) Provide guidelines, documents, software, and other tools to assist libraries, etc. in ful- 
filling this responsibility. 

The Panel discussed the 10 questions listed in the Data Issues Panel Charge and arrived at the following 
responses: 

1 . The SPDS can supply encouragement, guidelines, and ultimately provide a mechanism for financial 
support for data archiving, restoration, and curation. NSSDC is a recognized repository for data ar- 
chiving. However, where applicable, the PI for the mission, and his current institution should retain 
his or her data and be responsible for its restoration and curation. Ideally, all data should be archived. 
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However, the restoration and curation of archived data sets will be undertaken by (hose who have an 
interest, and the finances, to do so. 

Orphaned data sets, i.e. data which are no longer supportable by either the PI or his/her institution and are 
not wanted by any other organization, should be repossessed by the NSSDC which would act as a library for 
old data sets. Prudence strongly suggests that longterm archiving should include duplicated archives at 
widely separated sites. 

2. The SPDS should be sufficiently attractive to induce Pi’s of new missions to join and obtain correla- 
tive data sets. Pi’s may hold proprietary rights over their data sets for periods defined by NASA. 

3. Some criteria for determining which data sets should be restored include: uniqueness, the difficulty 
with which they were obtained, and their potential forbeing lost. However, the primary criterion must 
be heavy use, or the possibility of heavy use. 

4. Files should be self-documenting with enough information to enable scientific use. 

5. There should be an option for users to add comments upon problems they have encountered. 

6. An expert infrastructure is very helpful in interpreting data sets. 

However, we must recognize that the PI and Co-I’s won’t always be available. The SPDS nodes should 
therefore maintain records of related papers and recent data requests to assist future researchers. 

7. Archiving and documenting data sets must generally assume priority over improving formats or plac- 
ing data sets on-line. The Panel recognized that formats change and the technological advances will 
make it possible to place large amounts of data on-line in the near future. 

8. Archiving Level 0 data is highly desirable and should be recommended in order to economically al- 
low for changes in processing routines. It is recognized that such data will be accessed in conjunction 
with a set of pajeessing routines which both culturize the data and put it in suitable units with the 
minimum loss of time resolution. Lower resolution data along with derived data products may be ap- 
propriate in many instances. These will require no additional connections and generally can be used 
as is. 

9. We cannot afford to place all data (particularly older datasets) in a standard format. We expect a grad- 
ual evolution to a preferred one or two formats. For the foreseeable future, we will need format trans- 
lators. 

10. Catalogues should contain information concerning the instrument, satellite, format of the data, a 
timeline of the instrument/satellite events, and the location of the ephemeris. 

1 1 . We had two additional points: 

• If SPDS proves cost-effective, it will be in a position to suggest guidelines to NASA for 
requirements it might impose upon future missions and data sets. 

• We reiterated our interest in including non-NASA data sets in the SPDS system, i.e. 

NOAA, ESA, ground-based, and DoD data sets. 
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Recommendations of Data Systems Panel 

Given the lack of prospects for any near-term funding sufficient to allow significant enhancements in 
SPDS capabilities beyond those currently in place, the Data Systems Panel concentrated on maximizing the 
scientific usefulness of a lean data system. 

Critical Functionalities 

The Panel identified three critical functionalities of a Space Physics Data System: the delivery of self- 
documenting data, the existence of a matrix of translators between various standard formats (IDFS, CDF, 
netCDF, HDF, TENNIS, UCLA fiat file, and FITS), and a network-based capability for browsing and ex- 
amining inventory records for the system’s data holdings. The translators, as well as useful data reduction 
and analysis tools, should be made available via anonymous File Transfer Protocol (FTP) from central sites. 
The inventory system would have both central and distributed entry points (with the central node pointing 
to the latter), with the inventory records at each node or subnode transmitted in a standard format. (This 
could be a simple ASCII flat file with certain required and optional fields describing the data holdings, data 
access methods, and points of contact for expert advice on analysis of the data.) 

Desiderata 

The Panel also enumerated additional, desirable capabilities of an SPDS that might be dependent on addi- 
tional resources: a centralized bulletin board service and/or mailing list server for distribution of software 
update and data holding news, and data browse/display tools. A Usenet news group could be an effective 
method of keeping the community up to date with new data sets, software, and hardware available at the 
various nodes and end-user sites, and would not require moderation. A central FTP service could aid in the 
distribution of analysis and visualization software obvious desiderata in themselves as well as a source tor 
other software and data (e.g., models, educational software, cross-sections, etc.). Whenever possible, such 
information should be shared with the Planetary Data System (PDS) and the Astrophysics Data System 
(ADS) communities. 

The SPDS nodes should log the usage of various data holdings, and users of those data holdings should be 
informed of the appropriate wording for acknowledging the support of the node/P.I. providing the service. 

System Level Standards 

Once again considering the austere funding environment, as well as the diversity of systems in place at the 
nodes listed in the concept document and potential subnodes, the panel specified only TCP/IP network inter- 
faces (Telenet, FTP, SMTP, and perhaps WAIS, gopher, and similar distributed data access facilities) and the 
seven file formats listed above as system-wide standards. There would be no impetus (from the SPDS alone) 
to reformat existing data sets if the matrix of translators existed. 
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Role of NS S DC 

In addition to continuing its traditional roles as the Master Directory server, central data copying facility, 
and final, deep archive, the NSSDC can also serve the SPDS user community by providing a bulletin board 
and/or mailing list for announcements of general interest, and anonymous FTP service for data format trans- 
lators, models, and other software tools of general interest. The NSSDC could also be used to help establish 
an e-mailing list (such as the Solarmail facility in use by solar physicists) for the space physics community. 
As an SPDS node, the NSSDC should provide access to orphaned data sets. 

Functionality of Directories, Catalogs, and Inventories 

As indicated in the critical functionalities section, the role of directories and inventories is to facilitate 
access to data holdings. 

Directories should therefore serve as pointers to distributed inventories, in a standard format, that contain 
sufficient information to characterize the data holding sufficiently to allow the average researcher to decide 
whether the data are appropriate to the investigation under consideration, and if so, to identify the parts of 
the data holding that meet his/her particular requirements. 

Distribution and Centralization 

The Panel feels that a central facility could not only continue to provide the traditional services of Master 
Directory maintenance and facilities for copying large quantities of data, but could also provide a 

bulletin board service, gopher, or mail exploder and anonymous FTP server for software and notices of 
community interest. All other roles should continue to be performed at the nodes or subnodes, including 
software development, updates of data inventories, translators for new formats or between platform-specific 
internal data representations, and so on. The Panel endorses the concept document’s emphasis on a distrib- 
uted system, based on the expertise of the PI group or node-resident, data center scientific staff. Systems 

capable of accessing data at two or more nodes, and software distributions portable to a variety of end- 
user platforms, arc particularly to be encouraged. 

Commonality of Interfaces 

The overriding consideration for any SPDS interface should be ease of use by a technically competent 
investigator. The only critical 

interoperability requirement is network access, or if necessary, dial-in access to a central facility con- 
nected to the Internet. 
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SPDS as a Technology Clearing House 

The SPDS should provide bulletin boards and/or news group(s) for exchanging information on new 
technology implemented by the node and user community. Such information should be given the widest 
possible distribution in the community, and communication should be established with communities with 
similar data technology interests, such as the Planetary and Astrophysics communities. 

Support Priorities 

The Panel feels the Space Physics Division should express its support for NASA’s efforts to lead in the 
implementation technologies, such as ATM, that would significantly increase the bandwidth of data com- 
munications with currently bandwidth-limited sites. Any effort at accelerating NASA’s transfer of this 
technology to the university community should likewise be supported. 


Evaluation of Demo Systems 

Comments on SwRI system: excellent data display and visualization facilities, but project-spacecraft- 
instrument-virtual instrument hierarchy can be misleading to inexperienced investigators looking for physi- 
cal parameters. The multiplicity of IDFS file types necessary for a complete specification of a single data 
unit was also seen as a drawback for data ported to end-user systems. The IDFS file system is nonetheless 
a good example of forcing the data provider to make the data self-documenting. 

Panel members were impressed as well with both the DITDOS systems capabilities for inventorying and 
browsing data, and the user interlaces developed at the SDAC. 

A Suggestion for a Community Survey 

As an aid to SPDS nodes developing appropriate software interfaces, the space physics community 
should be polled, preferably by e-mail, on such subjects as preferred interface (X windows, Microsoft Win- 
dows, VT terminal emulation, etc.), monitor display capabilities (bit depth, number of pixels, color capabili- 
ty), data analysis software of choice (IDL, other analysis packages), and available data communications 
(TCP/IP, DECnet, neither). 
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Recommendations of Software Panel 


Overview 

The Software Panel of the SPDS was convened to discuss and make recommendations on the software-re- 
lated aspects of a future SPDS. The main focus of the Software Panel was to define the requirements and 
priorities for SPDS to support common data analysis and data visualization tools and packages. 

It is hoped that through a combination of data and software collection of compatible systems will emerge 
which can exchange data and metadata with minimum overhead. There are many existing applications, both 
commercial and public domain, which can be enhanced or extended so that they are compatible. The devel- 
opment of data format translators appears to be the key in creating a confederation of compatible applica- 
tions and data systems. 

Recommendations 

The Software Panel makes the following recommendations: 

1 . That SPDS through NASA funding begin an initiative to develop data format translators which will 
convert between specific data formats. The specific data formats are to be defined by the Data Sys- 
tems Panel. It is believed that no one format can solve all data analysis and visualization require- 
ments. 

2. That SPDS develop a catalog to provide information to the community about the availability of all 
useful software that has been developed under NASA funding (hence in the public domain). This cat- 
alog should contain information about the programming language, available documentation, relative 
quality of the code, available support, and on the location of and contact point for the software. 

3. That SPDS should not undertake a new development effort. Rather, NASA should provide funding 
to extend and enhance existing systems to meet the requirements and needs of an SPDS. 

4. That SPDS encourage and NASA fund the porting of meritorious applications to platforms other than 
that on which the application was originally developed. The selection of which applications to port 
should be done using a peer review process. 

5. That SPDS state as a policy that new application development should meet some minimum standards 
and that adherence to this policy become a contractual obligation. It is believed that NASA’s current 
software development policy imposes too much overhead on software projects. The application de- 
velopment standard should include, but not be limited to, providing a Users Guide, providing an 
Installation Guide, coding in a standard language which is supported on multiple platforms, writing 
portable code (can run on multiple platforms), and internally documenting code with comments pre- 
ceding each callable component (function, subroutine, et al.) of an application. These comments 
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should include a description of what the components do and the algorithm used. In addition, argu- 
ments, external variables, and any parameters which influence the operation of the component must 
be identified and described. 

6. That SPDS encourage projects and groups that adopt Commercial off-the-Shelf (COTS) systems to 
be sensitive to data portability issues so that data can be used in other systems. Pathways to COTS 
which are widely used should be provided by NASA, users of the COTS, or suppliers of COTS. 

7. That NASA should assume a capital equipment responsibility and provide funds to insure that the 
research community have a computing environment which docs not act as a limiting factor in general 
distribution and use. as well as development, of software systems. 

8. That SPDS identify as part of a Software Development Policy the platforms and environments on 
which software should run. The Software Panel recommends that the following hardware architec- 
tures be supported: SPARC. VAX, Alpha, Intel x86, Silicon Graphics (SGI), Hewlett-Packard (HP), 
and Mac. That the following operating systems be supported: DOS, SunOS, Solaris. VMS. MacOS, 
Utlrix, and AIX. That the following window systems be supported: X-windows (X 1 1R5) with Motif 
and Open Look, MS-Windows, and Mac. It is acknowledged that this list is valid only at the time of 
this report and will undoubtedly change with time. NASA’s policy should reflect this inevitability. 

9. That SPDS select systems which have low maintenance overhead. Forexamplc, mail list servers, bul- 
letin board services, Usenet news groups and data systems which are configurable and which deter- 
mine data holdings each time they are run. 

Discussion Summary 

These recommendations were derived from discussions of a series of questions posed by the SPDS Steer- 
ing Committee. In some cases the posed question required some interpretation in order to focus the discus- 
sion on software issues. The following are the questions and a summary of the discussions: 

I . On-Line Library 

(a) Should SPDS provide an on-line library of existing software? A catalog of existing soft- 
ware should be implemented. Providing direct access to a central repository (library) of 
software is as not important as a catalog since the burden of maintaining current versioas 
may not be cost effective. In addition the expertise on a specific piece of software typically 
resides with the provider, so software should be obtained from the original author. Further- 
more, applications should be accompanied by test or example data sets so that the user can 
verify an installation and explore an applications capabilities. 

(b) How should this software be cataloged? By placing in a queriablc system information about 
the programming language, available documentation, relative quality of the code, available 
support, and where to obtain the software. 
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(c) What software documentation standards should apply? For applications, a minimal require- 
ment would be providing a Users Guide and an Installation guide, coding in a standard lan- 
guage which is supported on multiple platforms, writing portable code (can run on multiple 
platforms), internally documenting code with comments preceding each callable compo- 
nent (function, subroutine, et al) of an application. These comments should include a de- 
scription of the functions of the components and the algorithm used. In addition, 
arguments, external variables, and any parameters which influence the operation of the 
component must be identified and described. 

2. New Software 

(a) Should SPDS develop new software to support data analysis and/or data visualization? No. 
Existing software should be enhanced or extended to meet SPDS needs. Enhancement 
should including porting of code which may exist on one platform to the platform where the 
need exits. If no software currently exists that can meet specific SPDS needs, then develop- 
ment of new software should funded. 

(b) What software documentation should apply? See lc. 

(c) How should this software be distributed? See la. 

(d) What kinds of new software should be developed? Data format translators to provide 
bridges between existing data systems and applications including both public domain and 
major commercial software packages (i.e., IDL and AVS). 

3. Software Toolbox 

(a) What should the software toolbox contain to support data providers? Data format transla- 
tors and the software catalog. 

(b) What should the software toolbox contain to support data users? Data lormat translators 
and the software catalog. 

4. Desirable Aspects 

(a) What are the desirable aspects of the surveyed data systems for SPDS to consider? It was 
decided that the Panel would not provide an itemized list. All of the systems demonstrated 
met at least one of the recommendations of the panel. In addition, this question seemed 
more appropriate for the Data System Panel to address. 

(b) What are the undesirable aspects of the surveyed data systems for SPDS to consider ? ft was 
decided that the panel would not provide an itemized list. 

5. Development of Tools 

(a) Should SPDS sponsor development of tools that could be freely distributed? SPDS should 
encourage the sharing of existing software and actively work to make it easier to obtain 
existing software. No new development initiatives should be undertaken unless there are no 
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existing tools to address the problem. Freely distributed software was considered a high 
priority activity. 

(b) Should SPDS define a framework that emphasizes increasing reliance on Commercial off- 
the-shelf (COTS) software? No, the choice of COTS software should be left up to the indi- 
vidual. However, SPDS should support activities that will provide data format translators 
that will pennit data to be used by COTS. Hopefully, the supplier of the COTS could be 
encouraged to support data formats identified by SPDS and standard formats. It was also 
noted that no COTS technology assessment group should be a part of the SPDS. 

(c) Is there a need for SPDS to act as a software clearing house? A software information clear- 
ing house (for COTS and public domain software) that utilizes community input should be 
pursued. Actual implementation could be a mail list server, or a moderated or unmoderated 
bulletin board sendee. Acting as a software repository is not considered as high a priority 
as dissemination of information, comments, and experiences. 

6. Define Standard Platfonm(s) 

(a) Is there a need to define a standard platform or platforms that will be the focus for any 
SPDS software support? If so, what should they be? In order to define a standard platform, 
a stable hardware and operating system market must exist. Since this is market influenced 
by communities outside of SPDS, choosing a standard platform does not appear to be vi- 
able. However, it is recognized that the current trend is towards UNIX systems that run X- 
windows on a variety of architectures and Windows-NT running on Intel architectures. Tire 
emphasis should be on developing portable code so that it may easily be migrated as new 
technologies are introduced. A survey of some of the attendees of the workshop indicated 
that the platforms used by the community are diverse, and changing to a standard platform 
is not feasible. The major platforms and environments in use today are: 

Table TRD 


(b) How important as a funding priority should it be to bring access to a standard platform to all 
active members of the space physics community? NASA should assume a capital equip- 
ment respoasibility and provide funds to ensure that the research community have a com- 
puting environment that does not act as a limiting factor in the general distribution and use, 
as well as development of, software systems. The focus of such funding should be to insure 
that scientific research is accomplished without incurring additional costs due to redundant 
software development. 


-15- 


June 1-3, 1993 


DRAFT SPDS Report 


7. Common Formats 

(a) What should SPDS policy with respect to common formats be? Specific formats were left 
to the Data Panel to define, but the number of formats should be as low as possible. 

(b) What are the technical issues? There are no technical limitations to providing support for 
multiple standardized formats. The only limitations are resources. The fewer the formats 
the fewer resources must be brought to bear on providing support for the formats. 

Some Efforts Resulting from the Workshop 

Some participants at the workshop agreed to explore some of the recommendations of the Software Panel 
on a volunteer basis. The efforts to be undertaken are: 

• Building a DITDOS server to work off the CEDAR inventory and provide a off-line data 
ordering service. 

• Establishing an information server that will contain documentation on data formats which 
can be publicly accessed. 

It should be stressed that all the recommendations of the Software Panel cannot be achieved on a volun- 
teer basis. If NASA pursues an SPDS. it should provide sufficient funds to accomplish a fully functional and 
properly supported SPDS. 
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